Bypassing class drivers through virtual driver enablement

ABSTRACT

A virtual driver is enabled and a class driver is bypassed to provide at least one functionality different than that of the bypassed class driver. A filter driver is initialized in the stack of a class driver in order to bypass the class driver. The filter driver receives inputs associated with the input device and/or application emulating an input device and passes the input data to a virtual driver. The virtual driver provides data to an operating system for functionality that is at least partially different than that of the bypassed class driver.

BACKGROUND

When an input device or application emulating an input device isconnected to a computing system, hardware class drivers associated withthe input device are initialized to provide communication between theinput device and an operating system. In some situations, an inputdevice may use a hardware class driver from a different, more common,input device type to facilitate communication in a standard manner withthe operating system. As an example, touch digitizers are oftenassociated with mouse class drivers. Such an arrangement limits thefunctionality of the touch digitizer to that of a mouse device. Also,such a situation, limits the functionality an operating system makesavailable to a user of the machine for the input device.

SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key and/oressential features of the claimed subject matter. Also, this Summary isnot intended to limit the scope of the claimed subject matter.

A virtual driver is enabled and a class driver is bypassed to provide atleast one functionality different than that of the bypassed classdriver. A filter driver is initialized in the stack of a class driver inorder to bypass the class driver. The filter driver receives inputsassociated with the input device and/or application emulating an inputdevice and passes the input data to a virtual driver. The virtual driverprovides data to a configuration manager for functionality that is atleast partially different than that of the bypassed class driver.

BRIEF DESCRIPTION OF THE DRAWINGS

Non-limiting and non-exhaustive embodiments of the present invention aredescribed with reference to the following figures, wherein likereference numerals refer to like parts throughout the various viewsunless otherwise specified.

FIG. 1 represents an exemplary system overview for bypassing classdrivers through virtual driver enablement;

FIG. 2 represents an exemplary flow diagram for initializing a filterdriver and a virtual driver;

FIG. 3 represents an exemplary flow diagram for sending data to thevirtual driver;

FIG. 4 represents an exemplary flow diagram for responding to a requestfrom a configuration manager;

FIG. 5 represents an exemplary high level flow diagram for dataspecialization functionality; and

FIG. 6 represents an exemplary computing system for facilitatingbypassing class drivers through virtual driver enablement.

DETAILED DESCRIPTION

Embodiments are described more fully below with reference to theaccompanying drawings, which form a part hereof, and which show specificexemplary embodiments. However, embodiments may be implemented in manydifferent forms and should not be construed as limited to theembodiments set forth herein; rather, these embodiments are provided sothat this disclosure will be thorough and complete, and will fullyconvey the scope. Embodiments may be practiced as methods, systems ordevices. Accordingly, embodiments may take the form of an entirelyhardware implementation, an entirely software implementation or animplementation combining software and hardware aspects. The followingdetailed description is, therefore, not to be taken in a limiting sense.

The logical operations of the various embodiments are implemented (1) asa sequence of computer implemented steps running on a computing systemand/or (2) as interconnected machine modules within the computingsystem. The implementation is a matter of choice dependent on theperformance and/or functionality requirements of the computing systemimplementing the invention. Accordingly, the logical operations makingup the embodiments described herein are referred to alternatively asoperations, steps or modules.

When an input device is connected to a computing system, hardware classdrivers associated with the input device are initialized, according toan identification code the device may provide during initialization, toprovide communication between the input device and an operating system.For example, a mouse may be connected to a computing device via aUniversal Serial Bus (USB) port. Inputs associated with the mouse aredirected through a mouse class driver so that an operating system canutilize inputs from the mouse. Also, in many situations, an input devicemay use a hardware class driver from a different or more common inputdevice type to facilitate communication with the operating system. Forexample, a digitizer may initialize a mouse class driver to providebasic communication with an operating system. Such a situation limitsthe functionality of the digitizer to that of a mouse because the mouseclass driver recognizes mouse only device inputs. Such a configurationmay be implemented because device manufactures are not knowledgeableregarding writing certain types of function drivers. Such aconfiguration may also be implemented because not all operating systemstake advantage of the full functionality of the input device and canutilize the hardware class driver of another input device type for mostpurposes.

A virtual driver is enabled and a class driver is bypassed to provide atleast one different input device functionality than that of the bypassedclass driver. In another aspect, an input device is emulated by anapplication. A virtual driver is enabled and a class driver is bypassedto provide at least one different emulated input device functionalitythan that of the bypassed class driver. A filter driver is initializedin the normal driver stack for the hardware device or emulated hardwaredevice to bypass the normal class driver. The filter driver receivesinputs associated with the input device and passes the input data to avirtual driver. The virtual driver may provide functionality to aconfiguration manager different than that of the bypassed class driver.In this manner, rich functionality of an input device or emulated inputdevice may be used by an operating system without being restricted by aclass driver. As an example with a digitizer, touch confidencefunctionality may be enabled (or simulated) to determine when a touch isan input or a non-input touch. As another example with a digitizer,contact size functionality may be enabled to determine a type of touchinput. Also, device or software manufactures do not need to be concernedwith the type of operating system that the device or software isultimately associated. Furthermore, users of existing input devices orsoftware can benefit from additional or enhanced functionality inoperating systems without having to update their existing device.

FIG. 1 represents one exemplary system overview for bypassing classdrivers through virtual driver enablement. System 100 may includeaspects of a computing device. The computing device may include adesktop computing device, mobile computing device, a laptop, a personaldigital assistant, a notebook computer, a telephone, a cellulartelephone, a kiosk computing device and/or any other type of computingdevice that may be configured to interpret inputs from an input deviceor emulated input device. In one aspect, the computing device includescomputing device 400 as exemplified in FIG. 4.

System 100 includes digitizer 102, mouse 104, and mother board 106. Thedigitizer 102, mouse 104 and mother board 106 are included in FIG. 1 forexemplary purposes only. The disclosure herein may include any type andany combination of hardware elements for association with system 100.For example, digitizer 102 and mouse 104 are presented herein as twodifferent types of input devices. The disclosure herein pertains toother types of input devices such as an input pen, a joystick, akeyboard, a tactile input device, an audio input device a visual inputdevice or any other type of input device functional to provide an inputinto system 100. System 100 also includes display 108. Likewise, system100 is not limited to such an output device. Other output devices thatapply to the disclosure include a printer, a fax, a visual outputdevice, a tactile output device, an auditory output device and/or anyother type of output device for communicating an output from system 100.In another embodiment, system 100 includes emulated input devices. Insuch a situation, driver stacks receive input data from an applicationthat emulates a hardware device input. As set forth in this disclosure,the term “input device” means a hardware input device, an emulatedhardware device, and/or a combination of a hardware input device and anemulated hardware device. Accordingly, the disclosure herein, is notlimited to receiving an input from hardware device.

System 100 is also represented by operation flow diagram 110.Operational flow diagram 110 represents elements of the disclosureassociated with the initialization of one or more drivers for one ormore input devices. Operational flow diagram 110 depicts a driver stackassociated with two different input devices. Such a depiction is forexemplary purposes only. The disclosure pertains to a driver stack for asingle input device, several input devices, and emulated input device,and the combination of an input device and an emulated input device. Thedepiction of two driver stacks is for an example more fully set forthbelow.

In one embodiment, operational flow diagram 110 includes user mode 112and kernel 114. User mode 112 includes one or more configurationmanagers 116. Even though configuration manager 116 is depicted as partof the user mode 112, configuration manager may be associated withkernel 114 or a kernel driver. In a first exemplary scenario, Kernel 114includes bus driver 118, function driver 120, filter driver 122, mouseclass driver 124 and virtual driver 126. In another scenario, kernel 114includes bus driver 128, function driver 130 and mouse class driver 132.As stated, these scenarios are exemplary. Kernel 114 may include anycombination of scenarios depending on the number and type of inputdevices or emulated input devices. Even though the elements associatedwith module 110 are represent as separate elements, they may beintegrated as a single element performing several functions. Thisdisclosure is not limited to a single element or various elements incommunication with one another.

System 100 includes digitizer 102. Digitizer 102 may include a digitizerfor positioning on a front face of a display, an electromagneticdigitizer for positioning behind a display, an emulated digitizer or anyother type of digitizer for receiving an input. In one aspect, digitizer102 includes a digitizer for receiving a touch input. Display 108 mayinclude a display association with a computing device such as a desktopcomputing device, mobile computing device, a laptop, a personal digitalassistant, a notebook computer, a table pc, a telephone, a cellulartelephone, or a kiosk computing device. Mouse 104 may include any typeof mouse device or emulated mouse device for causing an input intosystem 100. Digitizer 102 and mouse 104 may be in communication withinput connection 134, and display 108 is in communication with outputconnection 136. Input connection 134 may include a USB connection,serial connection and/or any other type of input connection forfacilitating an input. Similarly, output connection 136 may include anS-video output connection, high definition output connection, and/or anyother type of output connection for facilitating an output.

In one embodiment, input connection 134, output connection 136, andelements of mother board 106 facilitate the initialization of driversduring an initialization operation of an input device. In one example,an input device may include mouse 104 having an associated mouse classdriver 132. Mouse 104 causes an input and bus driver 128 detects theinput. Bus driver 128 passes the data to function driver 130. Functiondriver 130 interprets the data. The input is passed to mouse classdriver 132. Mouse class driver responds to a read request fromconfiguration manager 116. Configuration manager 116 may process thedata to display the functionality of the mouse input on display 108. Inthis situation, configuration manager 116 interprets the response ascoming from a mouse device.

In another example, the input device may include digitizer 102.Digitizer 102 may be associated with mouse class driver 124. Digitizer102 causes an input and bus driver 118 detects the input. Bus driver 118passes the data to function driver 120. Function driver 120 interpretsthe data. The input data is then sent to filter driver 122 as opposed tomouse class driver 124. In another embodiment, filter driver 122optionally receives the input data. Stated another way, filter driver122 may by “turned on or off” depending on whether a user desires thedigitizer to function as a mouse device or a digitizer device. If theinput data was sent to mouse class driver 124, digitizer 102 would beassociated with the same functionality as mouse 104 as described abovein the mouse device scenario. However, if filter driver 122 receives theinput data and routes the data to virtual driver 126, functionalityassociated with virtual driver 126 is enabled as more fully set forthbelow. In one aspect of the disclosure, virtual driver 126 includes twotop level collections in its report descriptor. In one embodiment, thefirst top level collection has only a read report and the second toplevel collection has only an output report. Filter driver 122 detectsthe virtual driver and opens an output report of the virtual driver foraccess. The access may be exclusive to prevent other components fromaccessing the output report. Filter driver 122 channels the input datato the output report of the virtual driver. Virtual driver 126configures the data for digitizer 102, and virtual driver 126 completesoutstanding read requests from configuration manager 116 with the outputreport. Virtual driver 126 may include separate input and output reportsto facilitate communication with filter driver 122 and configurationmanager 116. In this situation, a configuration manager or configurationmanagers do not interpret the response to the request as coming from amouse device. In this situation, a configuration manager orconfiguration managers interpret the response to the request as comingfrom a digitizer device even though mouse class driver 124 isinitialized. In other aspects, configuration manager, virtual driver126, and filter driver 122 may communicate in association with namedpipes, a shared memory section, passing a name of a file handle to open,and/or a private channel.

Filter driver 122 and/or virtual driver 126 may also include dataspecialization functionality. For example when the data is received,coordinates may be transformed to better associate with a touch input ofdigitizer 102. Filter driver 122 and/or virtual driver 126 may alsocalibrate the data to compensate for an offset associated with adigitizer's position on a display. Filter driver 122 and/or virtualdriver 126 may further correct errors associated with a touch input. Asanother example, filter driver 122 and/or virtual driver 126 may smooththe data input to correct “noise” associated with a touch input. Ingeneral, filter driver 122 and/or virtual driver 126 may include anytype of data specialization functionality to make the functionality ofthe digitizer available to user mode component 116.

In this manner, virtual driver 126 provides functionality toconfiguration manager 116 at least partially different than that of thebypassed mouse class driver 124. As such, rich functionality ofdigitizer 102 may be used by an operating system without beingrestricted by mouse class driver 124. As is evident from the disclosureherein, any type of class driver may be bypassed by a filter driver andpassed to a virtual driver regardless of the type of hardware associatedtherewith and/or emulated hardware associated therewith.

FIG. 2 represents an exemplary flow diagram for initializing a filterdriver and a virtual driver. Operation flow 200 begins at startoperation 202 and flows to operation 204 where an electronic signaturefor a hardware device is received. In the situation where the hardwaredevice is an emulated hardware device, the electronic signature may be aflag or indicator identifying the emulated hardware device. Anelectronic signature may be initiated by plugging in a device, loading adevice or turning on a device. In one aspect a plug-and-play managerreceives the electronic signature of the device and obtains a hardwareidentification from the signature.

Operational flow 200 continues to operation 206 where a driver store isaccessed. The driver store may include a set of drivers for severaldevice types. Operation flow 200 continues to decision operation 208where it is determined whether the electronic signature matches a driverstack. When the electronic signature does not match any of the driverstacks associated with the driver store, operational flow 200 continuesto operation 210 where a recognition error occurs. Stated another way,the system does not recognize the device connected to the system.Operational flow 200 continues to decision operation 212 where it isdetermined whether another electronic signature is received. Whenanother electronic signature is received, operation flow 200 loops backto operation 206 where the driver store is again accessed. When anotherelectronic signature is not received, operational flow 200 continues toend operation 222.

When, at decision operation 208, the electronic signature matches adriver stack associated with the driver store, operational flow 200continues to decision operation 214. At decision operation 214, it isdecided whether the driver stack includes an associated filter driver.When the driver stack does not include an associated filter, operationflow continues to operation 216 where the stack that does not have thefilter driver is initialized. As an example with reference to FIG. 1, adriver stack including bus driver 128, function driver 130 and mouseclass driver 132 may be initialized. In this example, a filter drivermay not exist because mouse device 104 is connected to mouse classdriver 132. From a functionality standpoint, in most situations, thefunctionality of the mouse is optimal to user mode component 116 becauseall the functionality of the mouse is interpreted by mouse class driver132. Operational flow 200 continues to end operation 222

When, at decision operation 214, it is decided that the driver stackincludes an associated filter driver. Operational flow 200 continues tooperation 218 where the stack that includes the filter driver isinitialized. As an example with reference to FIG. 1, a driver stackincluding bus driver 118, function driver 120, filter driver 122, andmouse class driver 132 may be initialized. In one embodiment, mouseclass driver 124 is initialized and receives input data when the filterdriver does not optionally bypass mouse class driver 124. Mouse classdriver 124 is depicted in FIG. 1 as dashed lines because, in one aspect,mouse class driver 124 is initialized, but mouse class driver 124 doesnot receive input data. In this example, a filter driver may exist tobypass mouse class driver 124. From a functionality standpoint, ifdigitizer data was sent to mouse class driver 124, digitizer 102 wouldbe associated with the same functionality as a mouse. However, in thissituation, filter driver 122 receives the digitizer data and routes thedata to virtual driver 126 to provide a richer functionality than couldbe provided by mouse class driver 124.

Operational flow 200 continues to operation 220 where the virtual driveris initialized. Even though operational flow 200 depicts operation 220following operation 218, operation 220 may come before operation 218, oroperation 220 and operation 218 may be associated with the sameoperation. In one aspect, the virtual driver is initialized by aplug-and-play manager in association with a registry key. When thevirtual driver is initialized, operational flow 200 continues to endoperation 222.

FIG. 3 represents an exemplary flow diagram for sending data to thevirtual driver. Operational flow 300 begins at start operation 302 andcontinues to decision operation 304 where it is determined whether aplug and play notification is detected. In another aspect, thenotification may include any type of notification for indicating thatthe virtual driver is available. When the plug and play notification isnot detected, operational flow 300 loops back until a plug and playnotification is detected. When a plug and play notification is detected,operational flow 300 continues to operation 306.

At operation 306, the filter driver detects the virtual driver.Operational flow 300 continues to operation 308 where the output reportof the virtual driver is opened. In one aspect, the output report of thevirtual driver is opened for exclusive access for the filter driver toprevent other components from opening the output report.

Operational flow 300 continues to decision operation 310, where it isdetermined whether the filter driver detects an input. For example, thefilter driver may detect an input from a mouse device. When an input isnot detected, operational flow 300 loops back until an input isdetected. When an input is detected, operation flow 300 continues tooperation 312 where the input is channeled to the output report of thevirtual driver. Operational flow 300 continues to end operation 314.

Even though operational flow 300 is described in association with anoutput report, the filter driver may also communicate with the virtualdriver in association with named pipes, a shared memory section, and/ora private channel.

FIG. 4 represents an exemplary flow diagram for responding to a requestfrom a configuration manager. Operational flow 400 begins at startoperation 402 and continues to operation 404 where a handle is providedto one or more configuration managers for access to the input report ofthe virtual driver. Operational flow 400 continues to operation 406where the virtual driver receives a request from the user mode componentfor data. The virtual driver receives output report data from the filterdriver as indicated by operation 408. In one aspect, the virtual driverincludes two separate top level collection reports. These reportsinclude the output report and the input report. The separate top levelcollection reports facilitate limited access to the reports. Operationalflow 400 continues to operation 410 where the output report data isassociated with the input report to facilitate a response to anyrequests by configuration managers having a handle associated with theinput report. In associating the data with the input report, the virtualdriver configures the data to provide different functionality than thatof a bypassed class driver. Operational flow 400 continues to endoperation 412.

Even though operational flow 400 is described in association with anoutput report, the configuration manager may also communicate with thevirtual driver in association with named pipes, a shared memory section,and/or a private channel.

FIG. 5 represents an exemplary high level flow diagram for dataspecialization functionality. Operational flow 500 begins at operation502 and continues to operation 504 where the filter driver obtains datadestined for a class driver. Operational flow 500 continues to decisionoperation 506 where it is decided whether the filter driver specializesthe data. Data specialization may include transforming coordinates ofthe data to better align with the input device. Data specialization mayalso include calibrating the data to compensate for an offset associatedwith the input device. Data specialization my further include correctingerrors associated with an input of the input device. As another example,data specialization may include smoothing a data input to correct“noise” associated with an input. In general, data specialization mayinclude any type of data specialization functionality to make thespecialized functionality available to an operating system. When it isdecided to specialize the data, operational flow 500 continues tooperation 508. Likewise when it is decided not to specialize the data,operational flow 500 continues to operation 508.

At operation 508, the data is sent to the virtual driver as previouslydiscussed. Operational flow 500 continues to decision operation 510where it is decided whether the virtual driver specializes the data. Asstated, data specialization may include transforming coordinates of thedata to better align with the input device. Data specialization may alsoinclude calibrating the data to compensate for an offset associated withthe input device. Data specialization my further include correctingerrors associated with an input of the input device. As another example,data specialization may include smoothing a data input to correct“noise” associated with an input. In general, data specialization mayinclude any type of data specialization functionality to make thespecialized functionality available to an operating system. When it isdecided to specialize the data, operational flow 500 continues tooperation 512. Likewise when it is decided not to specialize the data,operational flow 500 continues to operation 512.

At operation 512, the virtual driver sends the data to the configurationmanager as previously discussed above. Operational flow continues to endoperation 514.

As is evident from the disclosure herein, other combinations of inputdevices, emulated input devices, class drivers, and virtual drivers arecontemplated. For example, the input device may include a keyboard, thehardware class driver may include a keyboard class driver, and thevirtual driver may include a virtual mouse driver. In such a situation,the operating system would open mouse functionality to the keyboard. Asanother example, the input device may include a joystick, the hardwareclass driver may include a joystick class driver and the virtual drivermay include a virtual mouse driver. In such a situation, the operatingsystem would open mouse functionality to the joystick. As yet anotherexample, joystick manufactures may implement mouse drivers forjoysticks. In such a situation, a filter driver may be implemented tobypass the mouse class driver and route input data to a virtual joystickdriver so the operating system can open joystick functionality to thejoystick.

Referring to FIG. 6, an exemplary system for implementing the inventionincludes a computing device, such as computing device 600. In a basicconfiguration, computing device 600 may include any type of stationarycomputing device or a mobile computing device. Computing device 600typically includes at least one processing unit 602 and system memory604. System memory 604 typically includes operating system 605, one ormore applications 606, and may include program data 607. Applications606 may include application 611 for emulating a hardware device. Thisbasic configuration is illustrated in FIG. 6 by those components withindashed line 608.

Computing device 600 may also have additional features or functionality.For example, computing device 600 may also include additional datastorage devices (removable and/or non-removable). Such additionalstorage is illustrated in FIG. 6 by removable storage 609 andnon-removable storage 610. Computing device 600 may also have inputdevice(s) 612 such as a keyboard, mouse, pen, voice input device, touchinput device, digitizers, etc. Output device(s) 614 such as a display,speakers, printer, etc. may also be included.

Computing device 600 also contains communication connection(s) 616 thatallow the device to communicate with other computing devices 618, suchas over a network or a wireless network. Communication connection(s) 616is an example of communication media. Communication media typicallyembodies computer readable instructions, data structures, programmodules or other information delivery media.

Although the invention has been described in language that is specificto structural features and/or methodological steps, it is to beunderstood that the invention defined in the appended claims is notnecessarily limited to the specific features or steps described. Rather,the specific features and steps are disclosed as forms of implementingthe claimed invention. Since many embodiments of the invention can bemade without departing from the spirit and scope of the invention, theinvention resides in the claims hereinafter appended.

What is claimed is:
 1. A computer-implemented method for bypassing aclass driver, the method comprising: receiving a signature of an inputdevice, wherein the signature is associated with a digitizer;recognizing the digitizer as a mouse class device; in response torecognizing the digitizer as a mouse class device, initializing a driverstack having a mouse class driver; determining whether the driver stackis associated with a filter driver; when the driver stack is associatedwith the filter driver, initializing the filter driver in the driverstack below the mouse class driver to bypass the mouse class driver,initializing a virtual driver to communicate with the filter driver andat least one configuration manager, wherein initializing the virtualdriver includes opening an output report of the virtual driver foraccess by the filter driver, opening an input report of the virtualdriver, and providing a handle of the input report to the at least oneconfiguration manager; receiving input data from the digitizerrecognized as the mouse class device; bypassing the mouse class driverby routing the input data through the filter driver to the output reportof the virtual driver; causing the virtual driver to specialize theinput data according to at least one function of the virtual driver;providing the specialized input data to the at least one configurationmanager; and causing a computer processor to process the specializedinput data to recognize the specialized input data for an application incommunication with the configuration manager.
 2. Thecomputer-implemented method of claim 1, wherein the digitizer is atleast one of a hardware digitizer and an emulated digitizer.
 3. Thecomputer-implemented method of claim 1, wherein the signature is a flagindicator.
 4. The computer-implemented method of claim 1, wherein theinput data from the digitizer is recognized as a mouse input.
 5. Thecomputer-implemented method of claim 1, wherein causing the virtualdriver to specialize the input data includes transforming coordinatesassociated with an input location of the input data.
 6. Thecomputer-implemented method of claim 1, wherein causing the virtualdriver to specialize the input data includes compensating for an offsetassociated with the input data.
 7. The computer-implemented method ofclaim 1, wherein causing the virtual driver to specialize the input dataincludes executing a data smoothing function to correct noise associatedwith the input data.
 8. A computer-readable storage medium havingcomputer executable instructions for bypassing a class driver, theinstructions for performing operations comprising: receiving a signatureof an input device, wherein the signature is associated with an inputdevice having a first class type; recognizing the input device as aninput device having a second class type; in response to recognizing theinput device as a device having a second class type, initializing adriver stack having a second class type driver; determining whether thedriver stack is associated with a filter driver; when the driver stackis associated with the filter driver, initializing the filter driver inthe driver stack below the second class type driver to bypass the secondclass type driver, initializing a virtual driver to communicate with thefilter driver and at least one configuration manager; receiving inputdata from the input device recognized as the input device having thesecond class type; and bypassing the second class type driver by routingthe input data through the filter driver to the virtual driver, whereinthe input data is specialized by at least one of the filter driver andthe virtual driver.
 9. The computer-readable storage medium of claim 8,wherein the first class type is a touch input class.
 10. Thecomputer-readable storage medium of claim 8, wherein the second classtype is a mouse class.
 11. The computer-readable storage medium of claim8, wherein the input device is at least of a hardware input device andan emulated input device.
 12. The computer-readable storage medium ofclaim 8, wherein the input data is specialized by transformingcoordinates associated with an input location of the input data.
 13. Thecomputer-readable storage medium of claim 8, wherein the input data isspecialized by compensating for an offset associated with the inputdata.
 14. The computer-readable storage medium of claim 8, wherein theinput data is specialized by executing a data smoothing function tocorrect noise associated with the input data.
 15. A system for bypassinga class driver, the system comprising: at least one processor; and atleast one memory having computer executable instructions stored thereon,wherein the computer executable instructions are configured forperforming operations, comprising: receiving a signature of an inputdevice; recognizing the input device as a mouse class device; inresponse to recognizing the input device as a mouse class device,initializing a driver stack having a mouse class driver; determiningwhether the driver stack is associated with a filter driver; when thedriver stack is associated with the filter driver, initializing thefilter driver in the driver stack below the mouse class driver to bypassthe mouse class driver, initializing a virtual driver to communicatewith the filter driver and at least one configuration manager; receivinginput data from the input device recognized as the mouse class device;bypassing the mouse class driver by routing the input data through thefilter driver to the virtual driver; and causing specialization of theinput data by at least one of the filter driver and the virtual driver.16. The system of claim 15, wherein the input device is at least one ofa hardware digitizer and an emulated digitizer.
 17. The system of claim16, wherein the input data from the digitizer is recognized as a mouseinput.
 18. The system of claim 15, wherein causing specialization of theinput data includes transforming coordinates associated with an inputlocation of the input data.
 19. The system of claim 15, wherein causingspecialization of the input data includes compensating for an offsetassociated with the input data.
 20. The system of claim 15, whereincausing specialization of the input data includes executing a datasmoothing function to correct noise associated with the input data.